add to L69, so that they will appear in -h output.

This looks like a problem. Does OTLP Kafka exporter allow writing batches of spans as a single Kafka message?

can you please help me in fixing this!

It may be difficult to "fix" if by that you mean implementing support for receiving batches. The current consumer in Jaeger was designed to receive one span per message.

I suggest looking into whether OTEL Collector can be configured to send one span per message (Kafka exporter introduced in open-telemetry/opentelemetry-collector#1439), probably with some pipeline configuration. We would want to reference that in Jaeger docs to make it clear that batch per message is not supported. And we should log an error in the code above if more than one span is found in the batch.

@yurishkuro I was busy with my college exams, I will get on it right away

I've looked into this a bit. I don't think OTEL has an option right now to split a batch into multiple Kafka messages, and I suggest that's what needs to happen. While it may be less efficient, going the other way (i.e. supporting batches in Jaeger) would break an invariant that we currently maintain that all spans from a given trace ID end up in the same Kafka partition. The current OTEL collector code won't be able to maintain that invariant.

so can you please help me with understanding what i have to do?

We need to make a change to OTEL Kafka exporter to support a config flag that would force de-batching of the spans into one span per message.

Technically, we could also implement batch handling in the ingester. There are two ways of doing that:

1. change the unmarshaler signature a bit to allow returning arrays of spans and opportunistically try to save them one at a time. If one of them fails, the batch will be partially saved, and if retry happens the whole batch will be re-saved again. If this happens rarely enough it might be acceptable solution. We would need to verify how out metrics work, so that they don't count whole batch as +1.
2. [much larger change] upgrade our Storage API to allow batches of spans. Just to be clear, I don't think it's worth doing for this ticket, but some storage backends do support batch inserts. E.g. for Elasticsearch there is no particular sharding scheme in place, so it can save a batch of random spans in a single node (risk of hot partitions though, and OOMs if batches are very large). For Cassandra, sending batch of spans for different trace IDs means the receiving node will become a coordinator, will reshard them as needed, and communicate with other Cassandra nodes. We tried to avoid this mode in our current implementation by making sure the db client does the sharding upfront, to minimize extra hops. I don't remember how either backend would handle atomicity in case of a batch save.

I am trying the first of your suggestions.

change the unmarshaler signature a bit to allow returning arrays of spans

But I don't have the authority to commit to this branch.
Is it possible to get it?

Or I can create a new PR

new PR is fine. You can cherry-pick the commits from the original PR to give credit to the original author